Payment processing system, method and computer program product

ABSTRACT

Embodiments of the present invention provide a method and computer program product for least cost routing in payment processing. In an embodiment of the invention, a payment processing method can include receiving a transaction profile for a proposed transaction as payment for a purchase by a purchaser from a merchant at a card processing terminal configured to identify a card number for a card. The method further can include computing a cost of processing the proposed transaction for each of multiple different payment processors based upon the received transaction profile. The method yet further can include selecting one of the different payment processors corresponding to a lowest cost of processing computed for the received transaction profile. Finally, the method can include routing the proposed transaction to the selected one of the different payment processors.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to the field of payment processing andmore particularly to debit card and credit card processing of retailtransactions.

2. Description of the Related Art

For centuries, the retail sale of goods and services has permitted notjust payment in hard currency, but also payment by way of a promise toprovide hard currency. Raw forms of credit result from a mere promise—anaccount or “tab”. Modern sophisticated forms of credit include creditaccounts, such as those represented by a credit card. More recentadvancements in payments systems include the notion of a debit accountor debit account. Even more recent advancements in payment systemsprocess gift cards and other accounts of stored value. Each of creditcards, debit cards and gift cards require the coordination of anintermediary merchant account in which credit and debit card paymentscan be accepted by a merchant, and a payment processing service managingthe settlement of each transaction.

Conventional credit card transactions are sent electronically tomerchant processing banks for authorization, capture and deposit.Various methods exist for presenting a credit card sale to the paymentprocessor for processing. In all circumstances the account number isread by “swiping” a magnetic strip of a credit or debit card through acredit card terminal/reader, by communicating with a computer chipembedded in a credit or debit card, or by manual methods includingproviding the number manually through a Web site or interactive voiceresponse system.

Most payment transactions conducted in the world of brick and mortarsales utilize a credit card terminal. Generally, a credit card terminalis a dedicated piece of equipment often linked to a point of sale (POS)system. When a credit card or debit card is processed through theterminal, either through swiping or manual keying, the terminalestablishes a communicative connection with a specified paymentprocessing system to verify the credit card and authorize thetransaction. The transaction then can be stored in the terminal until a“polling window” opens. At that point, stored transactions can beuploaded resulting in the transfer of funds directly to a specifiedmerchant bank.

The use of a merchant account in payment processing is not withcost—literally. Specifically, the use of a merchant account can resultin the occurrence of a variety of fees, some periodic, and otherscharged on a per-item or percentage basis. Some fees are determined bythe provider of the merchant account. Other fees are passed through themerchant account provider to the credit card issuing bank according to aschedule of rates called interchange fees. Interchange fees generallyvary depending on card type and the circumstances of the transaction.For example, if a transaction originates by swiping a card through acredit card terminal the fee will be different than would be the case ifthe account information had been provided manually. In many cases, feesare established in order to minimize fraud.

At present, credit and debit card processing services deliver a genericoffering to merchants. The generic offering includes a pricing schemegenerally known as the “merchant discount rate”. Credit and debit cardprocessors typically base the merchant discount rate upon theinterchange rate, which is the base rate published by the cardassociations including Mastercard™ (Mastercard is a registered trademarkof Mastercard International Incorporated of Purchase, N.Y.) and Visa™(Visa is a registered trademark of Visa Inc. of San Francisco, Calif.).The card associations base the interchange rates upon a variety ofparameters including the type of card being used (regular, gold,loyalty, corporate, domestic, international, amongst others) in additionto the category into which the merchant belongs. Additionally, credittransactions are priced different from debit card transactions, anddebit cards include two different categories: PIN or signature based.

BRIEF SUMMARY OF THE INVENTION

Embodiments of the present invention address deficiencies of the art inrespect to payment processing and provide a novel and non-obvious methodand computer program product for least cost routing in paymentprocessing. In an embodiment of the invention, a payment processingmethod can include receiving a transaction profile for a proposedtransaction as payment for a purchase by a purchaser from a merchant ata card processing terminal configured to identify a card number for acard. The method further can include computing a cost of processing theproposed transaction for each of multiple different payment processorsbased upon the received transaction profile. The method yet further caninclude selecting one of the different payment processors correspondingto a lowest cost of processing computed for the received transactionprofile. Finally, the method can include routing the proposedtransaction to the selected one of the different payment processors.

Additional aspects of the invention will be set forth in part in thedescription which follows, and in part will be obvious from thedescription, or may be learned by practice of the invention. The aspectsof the invention will be realized and attained by means of the elementsand combinations particularly pointed out in the appended claims. It isto be understood that both the foregoing general description and thefollowing detailed description are exemplary and explanatory only andare not restrictive of the invention, as claimed.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

The accompanying drawings, which are incorporated in and constitute partof this specification, illustrate embodiments of the invention andtogether with the description, serve to explain the principles of theinvention. The embodiments illustrated herein are presently preferred,it being understood, however, that the invention is not limited to theprecise arrangements and instrumentalities shown, wherein:

FIG. 1 is a pictorial illustration of an transaction optimizationprocess for payment processing;

FIG. 2 is a schematic illustration of a payment processing systemconfigured for transaction optimization;

FIG. 3 is a flow chart illustrating a transaction optimization processfor payment processing;

FIG. 4 is a flow chart illustrating a process for transactionoptimization;

FIG. 5 is a pictorial illustration of a card processing terminalconfigured for electronic couponing; and,

FIG. 6 is a flow chart illustrating a process for electronic couponingin a card processing system.

DETAILED DESCRIPTION OF THE INVENTION

Embodiments of the invention provide transaction optimization forpayment processing. In accordance with an embodiment of the invention,payment in satisfaction of a purchase from a merchant by a purchaser canbe processed through the coordinate use of a card processing terminaland a credit card, debit card or other stored value card. A cardassociation for a swiped card in the card processing terminal can bedetermined and criteria requisite to a lowest rate charged by the cardassociation can be loaded. As well, optimization criteria pre-specifiedpreferentially by the merchant can be loaded. The card associationcriteria and the optimization criteria can be mapped to required datafor a transaction and the merchant can be prompted to provided therequired data through the card processing terminal or a computer displaycoupled to the card processing terminal. Only once the required data isprovided, the processing of a transaction on the swiped card canproceed.

Thereafter, a BIN can be determined for the swiped card as can atransaction profile such as the type of merchandise or servicepurchased, an identity of the purchaser, an invoice number, an amount ofthe transaction, or the zip code of the purchaser to name only a fewpossibilities. Using the transaction profile, the card association, theoptimization criteria and the BIN, a particular bank can be selected toprocess the transaction. Subsequently, the transaction can be assembledto include not only the card number of the swiped card, but the requireddata also. Finally, the assembled transaction can be transmitted to theselected bank. Optionally, prior to assembling the transaction, butsubsequent to obtaining a signature from the purchaser at the cardprocessing terminal, a display of a coupon can be provided in the cardprocessing terminal. At the option of the purchaser, the coupon can beredeemed through a selection in the card processing terminal and thetransaction when assembled can account for the redemption of the coupon.

In further illustration, FIG. 1 is a pictorial illustration of a processfor transaction optimization during payment processing. As shown in FIG.1, a card 110, such as a debit card, credit card or stored value cardcan be swiped through a card processing terminal 120 as satisfaction ofpayment for goods or services provided by a merchant to a purchaser.Transaction optimization system 130 can process payment with the card110 in order to optimize an interchange rate paid by the merchant inconsequence of the payment while meeting preferential criteria forprocessing payment established by the merchant.

In this regard, data required to be provided by the merchant to aselected bank 140 as part of the transaction in order to achieve aminimized fee payable by the merchant in consequence of the transactioncan be determined in advance of sending the transaction to the selectedbank 140. Thereafter, the merchant can be compelled to collect therequired data for use in assembling the transaction for transmission tothe selected bank 140. Of note, selected bank 140 can be selected inaccordance with BIN routing rules. Specifically, the BIN for the card110 can be determined from the card number of the card 110. Oncedetermined, a table can be consulted with the BIN to identify acorresponding one of the banks 140 to be selected in order to maintainaffinity between the bank issuing the card 110 and the bank selected toprocess the transaction.

The transaction optimization system 130 can include several modules150A-150G each including computer program code that when executed by aprocessor of a computer while loaded into the memory of the memory canachieve transaction optimization during payment processing. Inparticular, a lowest transaction cost routing module 150A can identifycharacteristics of the proposed transaction—essentially a transactionprofile that can include the type of card, the geographic location ofthe issuing institution for the card, the amount of the purchase, thetype of merchant, whether the card is swiped or the account number keyentered in lieu of swiping to name a few. The lowest transaction costrouting module 150 can compute a resulting interchange rate fordifferent ones of the banks 140 according to the transaction profile andcan select a particular one of the banks 140 to process the transactionby resulting lowest interchange rate.

By comparison, BIN routing optimization module 150B can select aparticular one of the banks 140 to receive the transaction according toa BIN identified for the card 110. Similarly, cash managementoptimization module 150G can route the transaction to a particular oneof the banks 140 according to pre-specified preferential bankingrelationships. In this regard, if the merchant can determine whichtransactions are routed to which of the banks 140 based on definedparameters, including; merchant ID, user ID, device type used to processthe transaction, product type (Visa, Mastercard, credit card, debitcard, etc), entry mode (swiped versus key entered), invoice number orcontract, transaction, purchase type, amount (based on a percentage oractual currency), volume and charge backs.

As an example, the merchant can specify all debit card transactions tobe routed to one of the banks 140 while all credit card transactions arerouted to another of the banks 140. As another example, a merchant withmultiple different merchant IDs for different portions of a retaillocation (e.g. sales, service and parts in an auto dealership) canspecify the routing of all charge-backs from one particular merchant IDto one of the banks 140 in order not to affect the pricing of otherportions of the retail location. As even yet another example, themerchant can specify that transactions from on-line customers are routedto one of the banks 140 and transactions from in-person customers arerouted to another of the banks 140 in as much as transactions fromon-line customers are viewed to be riskier and hence are expensive.

Interchange optimization module 150C can determine a card associationfor the card 110 and subsequently can identify data requisite to achievea lowest interchange rate for the determined card association. Forinstance, required data can include an invoice number or tax ID numberfor a commercial transaction, or requiring the swiping of the card 110rather than keying the card number at the card processing terminal 120.Subsequently, the merchant can be prompted to provide the required databefore the transaction can be routed to the selected one of the banks140.

Remaining modules include a merchant dashboard module 150D generating aset of reports based on the real time data of transactions andpresenting the reports to the merchant in graphical form while alsoevaluating actual data versus targeted parameters specified by themerchant. Remaining modules further include an instant alert module 150Fnotifying the merchant with an alert such as an e-mail or text messagein the event that a certain threshold has been breached such as anattempt by a clerk to perform an unauthorized transaction or an attemptto process a credit above a specified threshold, or in the event of anumber of credits having been processed which surpasses a typical numberof credits for a particular period of time, or in the event of atransaction exceeding a specified threshold amount. Finally, anelectronic couponing module 150E can be provided through which real-timecoupons can be presented graphically in the card processing terminal 120before routing a transaction and, upon redemption by a customer, thetransaction can be modified according to the coupon.

The process described in connection with FIG. 1 can be implemented in apayment processing system. In further illustration, FIG. 2 schematicallyshows a payment processing system configured for transactionoptimization. The system can include a point of sale computer 200configured with processor and memory coupled to a card processingterminal 210. The point of sale computer 200 can be configured forcommunicative coupling to different servers 230 for different cardprocessors from over a computer communications network 220. The point ofsale computer 200 further can be configured for communicative couplingto a transaction host server 240.

The point of sale computer 200 can host the execution in memory of thecash management optimization module 290A, the instant alert module 290B,the merchant dashboard 270 and also electronic couponing logic 280,though it is to be recognized, that any of the cash managementoptimization module 290A, the instant alert module 290B, the merchantdashboard 270 can execute in memory of the card processing terminal 210in the absence of the point of sale computer 200. By comparison, thetransaction host server 240 can host the execution in memory of routingmodule 250 including least cost routing, BIN routing and interchangeoptimization. The transaction host server 240 further can store aninterchange parameters and routing table 260 used to map a cardassociation for a card swiped at the card processing terminal 210 (orkey entered at either the card processing terminal 210) with interchangeoptimization criteria.

In operation, a card can be swiped at the card processing terminal 210(or the number of the card keyed into to either the card processingterminal 210 or the point of sale computer 200) in consummation of aproposed purchase. A card association can be determined from the numberof the card as can the BIN and a transaction profile for the proposedpurchase. The card association, number and BIN and transaction profilecan be provided to the routing module 250 in response to which therouting module can consult the table 260 to determine required data toachieve an optimum interchange, as well as a selection of a cardprocessor/bank to which the transaction is to be routed according to theBIN and the transaction profile. The determined required data can becommunicated to the card processing terminal 210 and/or point of salecomputer and one or more prompts can be rendered therein to capture therequired data.

Once the required data has been provided, a transaction can be assembledand forwarded to the transaction host server 240. The routing module 250in turn can route the transaction to a selected one of the cardprocessors/banks 230 according to the routing selected from the routingmodule 250 responsive to the BIN and transaction profile. Optionally,the routing of the transaction can be directed according topre-specified rules set forth by cash management optimization module290A. As an additional option, the instant alert module 290B cangenerate an alert when called for according to alert rules mapped toevents.

In yet further illustration of the overall operation of the paymentprocessing system of FIG. 2, FIG. 3 is a flow chart illustrating atransaction optimization process for payment processing. Beginning inblock 305, a card number can be extracted from a card that either hasbeen swiped at a card processing terminal, or keyed into the cardprocessing terminal or a point of sale terminal. In block 310, data canbe received from the card processing terminal or the point of saleterminal, such as transaction amount, name of card holder, zip code ofthe billing address of the card holder, or the identity of a clerkprocessing the transaction. In block 315, the data can be posted to thetransaction host server for processing.

In block 340, the transaction host can receive the data from theterminal and in block 345, optimization criteria can be retrieved forthe data. In block 350, the optimization criteria can be returned to theterminal and in block 320, the terminal can receive the optimizationcriteria, for example data requisite to be provided at the terminal inorder to optimize the interchange rate for the transaction. In block325, the operator of the terminal can be prompted to provide theinformation included as part of the optimization criteria, such as apersonal identification number, an invoice number, a billing zip code,etc. In block 330, a transaction can be assembled with the informationreceived in consequence of the prompt and the data received initially atthe terminal. Thereafter, in block 335 the transaction can be posted tothe transaction host server.

In block 355, the transaction can be received from the terminal and inblock 360, a bank/payment processor to which the transaction is to berouted can be determined, for example to provide a lowest cost oftransaction, or to meet a pre-specified preference established by themerchant, or both. In block 365 the transaction can be routed to aselected bank/payment processor. Finally, in block 370, an audit trailcan be written for the transaction for use in later reporting.

In even yet further illustration of an aspect of an embodiment of theinvention, FIG. 4 is a flow chart illustrating a process for optimizedtransaction processing. Beginning in block 405, a card number can beacquired for a card during payment processing of a purchase by apurchaser from a merchant through either or both of a card processingterminal or a point of sale terminal. In block 410, a card associationcan be determined from the card number. Further, in block 415, atransaction profile can be identified for the purchase, such as anamount of a proposed charge, merchandise type, identity of thepurchaser, type of merchant, etc. In block 420, optimization criteriacan be mapped to the identified card association and in block 425, datarequisite to an optimized interchange for the card association can bedetermined. Thereafter, in block 430, the merchant can be prompted toprovide the required data corresponding to the optimization criteria.

In block 435, the required data can be received either through the cardprocessing terminal or the point of sale terminal and in decision block440, if all data required by the optimization criteria has beenprovided, in block 445 a BIN can be determined from the card number.Using any combination of the optimization criteria, transaction profileand BIN, in block 450 a particular bank or payment processor can beselected and in block 455, a transaction can be assembled using therequired data provided by the merchant as well as the transactionprofile. Finally, in block 460 the transaction can be routed to theselected bank or payment processor. In this way, not only can theinterchange rate be minimized by compelling the merchant to collect therequisite data for a lowest possible interchange rate, but also thetransaction can be routed to a selected bank or payment processor bothto minimize the cost of the transaction and also to meet the preferenceof the merchant.

In one aspect of the embodiment, the card processing terminal can beconfigured for electronic couponing. In even yet further illustration,FIG. 5 pictorially depicts a card processing terminal configured forelectronic couponing. As shown in FIG. 5, a card processing terminal 510can permit the swiping of a card for payment processing and electronicsignature capture (along with transaction profile capture). A display530 can indicate details of the proposed transaction including aproposed transaction amount, a scanned card number and a name of thecard holder. Further, the purchaser can be prompted to provide datathrough prompts issued in the display 530.

Significantly, depending upon the transaction profile, a coupon oradvertisement 520 can be selected for display to the purchaser throughthe display 530 subsequent to capturing the transaction profile butprior to completing the transaction. Further, a prompt 540 can bepresented to the purchaser through the display 530 to redeem the couponin real-time. If the purchaser elects to redeem the coupon 520, thetransaction profile can be modified to reflect the application of thecoupon 520 and the modified transaction can be forwarded to thetransaction host server for routing to a bank or payment processor forprocessing.

By way of example, FIG. 6 is a flow chart illustrating an exemplaryprocess for electronic couponing in a card processing data processingsystem. Beginning in block 610, transaction detail can be collected fora proposed transaction at a card processing terminal and processedinitially through the transaction host, for example, in order to performinterchange optimization. In block 620, a signature can be captured forthe proposed transaction indicating an assent by the purchaser of thetransaction detail for the proposed transaction. In decision block 630,once it is determined that the signature has been captured, in block640, a coupon can be retrieved mapping to one or more aspects of thetransaction detail. Subsequently, the coupon can be displayed in thecard processing terminal in order to entice the purchaser to redeem thecoupon for a specific value. In decision block 660, if the purchaserelects to redeem the coupon, in block 670 the charge reflected in thetransaction detail can be reduced accordingly and in block 680 thetransaction can be forwarded to the transaction host for final routingto a selected bank or payment processor.

As will be appreciated by one skilled in the art, aspects of the presentinvention may be embodied as a system, method or computer programproduct. Accordingly, aspects of the present invention may take the formof an entirely hardware embodiment, an entirely software embodiment(including firmware, resident software, micro-code, etc.) or anembodiment combining software and hardware aspects that may allgenerally be referred to herein as a “circuit,” “module” or “system.”Furthermore, aspects of the present invention may take the form of acomputer program product embodied in one or more computer readablemedium(s) having computer readable program code embodied thereon.

Any combination of one or more computer readable medium(s) may beutilized. The computer readable medium may be a computer readable signalmedium or a computer readable storage medium. A computer readablestorage medium may be, for example, but not limited to, an electronic,magnetic, optical, electromagnetic, infrared, or semiconductor system,apparatus, or device, or any suitable combination of the foregoing. Morespecific examples (a non-exhaustive list) of the computer readablestorage medium would include the following: an electrical connectionhaving one or more wires, a portable computer diskette, a hard disk, arandom access memory (RAM), a read-only memory (ROM), an erasableprogrammable read-only memory (EPROM or Flash memory), an optical fiber,a portable compact disc read-only memory (CD-ROM), an optical storagedevice, a magnetic storage device, or any suitable combination of theforegoing. In the context of this document, a computer readable storagemedium may be any tangible medium that can contain, or store a programfor use by or in connection with an instruction execution system,apparatus, or device.

A computer readable signal medium may include a propagated data signalwith computer readable program code embodied therein, for example, inbaseband or as part of a carrier wave. Such a propagated signal may takeany of a variety of forms, including, but not limited to,electro-magnetic, optical, or any suitable combination thereof. Acomputer readable signal medium may be any computer readable medium thatis not a computer readable storage medium and that can communicate,propagate, or transport a program for use by or in connection with aninstruction execution system, apparatus, or device.

Program code embodied on a computer readable medium may be transmittedusing any appropriate medium, including but not limited to wireless,wireline, optical fiber cable, radiofrequency, and the like, or anysuitable combination of the foregoing. Computer program code forcarrying out operations for aspects of the present invention may bewritten in any combination of one or more programming languages,including an object oriented programming language and conventionalprocedural programming languages. The program code may execute entirelyon the user's computer, partly on the user's computer, as a stand-alonesoftware package, partly on the user's computer and partly on a remotecomputer or entirely on the remote computer or server. In the latterscenario, the remote computer may be connected to the user's computerthrough any type of network, including a local area network (LAN) or awide area network (WAN), or the connection may be made to an externalcomputer (for example, through the Internet using an Internet ServiceProvider).

Aspects of the present invention have been described above withreference to flowchart illustrations and/or block diagrams of methods,apparatus (systems) and computer program products according toembodiments of the invention. In this regard, the flowchart and blockdiagrams in the Figures illustrate the architecture, functionality, andoperation of possible implementations of systems, methods and computerprogram products according to various embodiments of the presentinvention. For instance, each block in the flowchart or block diagramsmay represent a module, segment, or portion of code, which comprises oneor more executable instructions for implementing the specified logicalfunction(s). It should also be noted that, in some alternativeimplementations, the functions noted in the block may occur out of theorder noted in the figures. For example, two blocks shown in successionmay, in fact, be executed substantially concurrently, or the blocks maysometimes be executed in the reverse order, depending upon thefunctionality involved. It will also be noted that each block of theblock diagrams and/or flowchart illustration, and combinations of blocksin the block diagrams and/or flowchart illustration, can be implementedby special purpose hardware-based systems that perform the specifiedfunctions or acts, or combinations of special purpose hardware andcomputer instructions.

It also will be understood that each block of the flowchartillustrations and/or block diagrams, and combinations of blocks in theflowchart illustrations and/or block diagrams, can be implemented bycomputer program instructions. These computer program instructions maybe provided to a processor of a general purpose computer, specialpurpose computer, or other programmable data processing apparatus toproduce a machine, such that the instructions, which execute via theprocessor of the computer or other programmable data processingapparatus, create means for implementing the functions/acts specified inthe flowchart and/or block diagram block or blocks.

These computer program instructions may also be stored in a computerreadable medium that can direct a computer, other programmable dataprocessing apparatus, or other devices to function in a particularmanner, such that the instructions stored in the computer readablemedium produce an article of manufacture including instructions whichimplement the function/act specified in the flowchart and/or blockdiagram block or blocks. The computer program instructions may also beloaded onto a computer, other programmable data processing apparatus, orother devices to cause a series of operational steps to be performed onthe computer, other programmable apparatus or other devices to produce acomputer implemented process such that the instructions which execute onthe computer or other programmable apparatus provide processes forimplementing the functions/acts specified in the flowchart and/or blockdiagram block or blocks.

Finally, the terminology used herein is for the purpose of describingparticular embodiments only and is not intended to be limiting of theinvention. As used herein, the singular forms “a”, “an” and “the” areintended to include the plural forms as well, unless the context clearlyindicates otherwise. It will be further understood that the terms“comprises” and/or “comprising,” when used in this specification,specify the presence of stated features, integers, steps, operations,elements, and/or components, but do not preclude the presence oraddition of one or more other features, integers, steps, operations,elements, components, and/or groups thereof.

The corresponding structures, materials, acts, and equivalents of allmeans or step plus function elements in the claims below are intended toinclude any structure, material, or act for performing the function incombination with other claimed elements as specifically claimed. Thedescription of the present invention has been presented for purposes ofillustration and description, but is not intended to be exhaustive orlimited to the invention in the form disclosed. Many modifications andvariations will be apparent to those of ordinary skill in the artwithout departing from the scope and spirit of the invention. Theembodiment was chosen and described in order to best explain theprinciples of the invention and the practical application, and to enableothers of ordinary skill in the art to understand the invention forvarious embodiments with various modifications as are suited to theparticular use contemplated.

Having thus described the invention of the present application in detailand by reference to embodiments thereof, it will be apparent thatmodifications and variations are possible without departing from thescope of the invention defined in the appended claims as follows:

1. A payment processing method comprising: receiving a transactionprofile for a proposed transaction as payment for a purchase by apurchaser from a merchant at a card processing terminal configured toidentify a card number for a card; computing a cost of processing theproposed transaction for each of multiple different payment processorsbased upon the received transaction profile; selecting one of thedifferent payment processors corresponding to a lowest cost ofprocessing computed for the received transaction profile; and, routingthe proposed transaction to the selected one of the different paymentprocessors.
 2. The method of claim 1, wherein receiving a transactionprofile for a proposed transaction as payment for a purchase by apurchaser from a merchant at a card processing terminal configured toidentify a card number for a card, comprises: receiving a transactionprofile for a proposed transaction as payment for a purchase by apurchaser from a merchant at a card processing terminal configured toidentify a card number for a card, the transaction profile comprising atype of card selected from the group consisting of credit and debit. 3.The method of claim 1, wherein receiving a transaction profile for aproposed transaction as payment for a purchase by a purchaser from amerchant at a card processing terminal configured to identify a cardnumber for a card, comprises: receiving a transaction profile for aproposed transaction as payment for a purchase by a purchaser from amerchant at a card processing terminal configured to identify a cardnumber for a card, the transaction profile comprising a geographiclocation of an issuing bank for the card.
 4. The method of claim 1,wherein receiving a transaction profile for a proposed transaction aspayment for a purchase by a purchaser from a merchant at a cardprocessing terminal configured to identify a card number for a card,comprises: receiving a transaction profile for a proposed transaction aspayment for a purchase by a purchaser from a merchant at a cardprocessing terminal configured to identify a card number for a card, thetransaction profile comprising an amount of the proposed transaction. 5.The method of claim 1, wherein receiving a transaction profile for aproposed transaction as payment for a purchase by a purchaser from amerchant at a card processing terminal configured to identify a cardnumber for a card, comprises: receiving a transaction profile for aproposed transaction as payment for a purchase by a purchaser from amerchant at a card processing terminal configured to identify a cardnumber for a card, the transaction profile comprising a merchant type ofthe merchant.
 6. The method of claim 1, wherein receiving a transactionprofile for a proposed transaction as payment for a purchase by apurchaser from a merchant at a card processing terminal configured toidentify a card number for a card, comprises: receiving a transactionprofile for a proposed transaction as payment for a purchase by apurchaser from a merchant at a card processing terminal configured toidentify a card number for a card, the transaction profile comprising anindication of whether the card had been swiped at the card processingterminal or whether an account number for the card had been keyed intothe card processing terminal in lieu of swiping.
 7. A computer programproduct comprising a computer usable medium embodying computer usableprogram code for payment processing, the computer program productcomprising: computer usable program code for receiving a transactionprofile for a proposed transaction as payment for a purchase by apurchaser from a merchant at a card processing terminal configured toidentify a card number for a card; computer usable program code forcomputing a cost of processing the proposed transaction for each ofmultiple different payment processors based upon the receivedtransaction profile; computer usable program code for selecting one ofthe different payment processors corresponding to a lowest cost ofprocessing computed for the received transaction profile; and, computerusable program code for routing the proposed transaction to the selectedone of the different payment processors.
 8. The computer program productof claim 7, wherein the computer usable program code for receiving atransaction profile for a proposed transaction as payment for a purchaseby a purchaser from a merchant at a card processing terminal configuredto identify a card number for a card, comprises: computer usable programcode for receiving a transaction profile for a proposed transaction aspayment for a purchase by a purchaser from a merchant at a cardprocessing terminal configured to identify a card number for a card, thetransaction profile comprising a type of card selected from the groupconsisting of credit and debit.
 9. The computer program product of claim7, wherein the computer usable program code for receiving a transactionprofile for a proposed transaction as payment for a purchase by apurchaser from a merchant at a card processing terminal configured toidentify a card number for a card, comprises: computer usable programcode for receiving a transaction profile for a proposed transaction aspayment for a purchase by a purchaser from a merchant at a cardprocessing terminal configured to identify a card number for a card, thetransaction profile comprising a geographic location of an issuing bankfor the card.
 10. The computer program product of claim 7, wherein thecomputer usable program code for receiving a transaction profile for aproposed transaction as payment for a purchase by a purchaser from amerchant at a card processing terminal configured to identify a cardnumber for a card, comprises: computer usable program code for receivinga transaction profile for a proposed transaction as payment for apurchase by a purchaser from a merchant at a card processing terminalconfigured to identify a card number for a card, the transaction profilecomprising an amount of the proposed transaction.
 11. The computerprogram product of claim 7, wherein the computer usable program code forreceiving a transaction profile for a proposed transaction as paymentfor a purchase by a purchaser from a merchant at a card processingterminal configured to identify a card number for a card, comprises:computer usable program code for receiving a transaction profile for aproposed transaction as payment for a purchase by a purchaser from amerchant at a card processing terminal configured to identify a cardnumber for a card, the transaction profile comprising a merchant type ofthe merchant.
 12. The computer program product of claim 7, wherein thecomputer usable program code for receiving a transaction profile for aproposed transaction as payment for a purchase by a purchaser from amerchant at a card processing terminal configured to identify a cardnumber for a card, comprises: computer usable program code for receivinga transaction profile for a proposed transaction as payment for apurchase by a purchaser from a merchant at a card processing terminalconfigured to identify a card number for a card, the transaction profilecomprising an indication of whether the card had been swiped at the cardprocessing terminal or whether an account number for the card had beenkeyed into the card processing terminal in lieu of swiping.